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REMARKS 

In response to the Office Action mailed on September 4, 2003, Applicants 
respectfully request reconsideration. Applicants are appreciative of the 
Examiner's withdrawal of the final rejection and submit the following remarks 
pointing out patentability of pending and newly added claims 27-36. Applicants 
would also like to thank the Examiner for the interview held on October 14, 2003 
to discuss distinctions between the pending claims and cited prior art. The 
following discussion of patentability is consistent with the interview held on 
October 14, 2003. Allowance of the previously pending and newly added claims 
is respectfully requested. 

Applicants have amended claims 1, 2, 8, 10, 17 and 19 and have added 
claims 27-36 to expedite prosecution of the present application towards 
allowance. No new matter was added when amending or adding the claims. 
The submission of these amendments and addition of claims should not be 
interpreted as acquiescing to the Examiner's rejections and analysis of the cited 
prior art. 

Claims 1-20 and 22-26 were previously pending in this Application. 
Claims 27-36 are being added via this Amendment. Thus, after entry of this 
Amendment, claims 1-20 and 22-36 will be pending. 

The following remarks address the rejections of claims 1-20 and 22-26 as 
set out in the present Office Action and patentability of newly added claims 
27-36. Note that claim 21 was previously cancelled. 

Rejection of Claim 2 under 35 U.S.C. 5112 

The Examiner has rejected claims 2 under 35 U.S.C. § 1 12 (paragraph 2) 
as being indefinite for failing to particularly point out and distinctly claim the 
subject matter that Applicants regard as the invention. In particular, the 
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Examiner notes that there is no antecedent basis for "the data communications 
device" as recited in claim 2. 

Applicants have amended claim 2 in various particulars addressing the 
issue as noted by Examiner and are appreciative of Examiner's comments to 
place the claims in better condition for allowance. 

Rejections of Claims 1. 3, 7-9, 10, 12, 16-18 and 22-26 under 35 U.S.C. § 102 

The Examiner has rejected claims 1, 3, 7-9, 10, 12, 16-18 and 22-26 
under 35 U.S.C. § 102(e) based on the teachings of Cave, et al. ( (U.S. Patent 
6,404,746). 

Indeed, the Cave reference is directed toward controlling a media stream. 
However, Cave does not disclose a technique of intercepting a request signal 
from a request signal source in which the request signal is destined for a host 
computer that would otherwise respond with control information as recited in 
claim 1 . Applicants have added the limitation that the request signal includes a 
destination address for transmitting the request signal to the host computer. It is 
respectfully submitted that Cave nor any other cited reference teaches or 
suggests these aspects of the claimed invention. 

To support the rejection of claim 1 , the Office Action states that "the signal 
normally would go to the gateway 626 at the receiving end which would respond 
with control information (see figure 3 and columns 12 and 13)." The Office 
Examiner likens the "request signal" in claim 1 to the electronic signal generated 
(in Cave) by gateway 606. 

Consistent with the interview held with the Examiner on October 14, 2003, 
Applicants would like to point out the teachings of Cave. In particular, Applicants 
would like to point out text of Cave and how such a system operates to connect a 
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caller at telephone 618 of FIG. 3 in Cave to VRU 600 and, eventually, to a caller 
at telephone 630 after being provided a second phone number. For example, 
Cave discloses a method of receiving an incoming call from telephone 618 at 
VRU 600 and specifically recites that: 

"In order for telephone 618 to connect to VRU 600, telephone 618 
must first connect to originating gateway 606 via PSTN 608, generally 
using a G.71 1 data format ... Gateway 606 then packetizes the data and 
attaches the appropriate headers to the packets for transmission to packet 
VRU 600 across packet network 602." (Cave, column 12, lines 46-54) 

In order to understand how telephone 618 connects with telephone 630, one 
must review Figures 4a, 4b, 4c and 4d and corresponding text as well as the 
H.323 standard and G.71 1 data format. Note that Cave discusses generalities of 
his invention with respect to FIG. 3 and does not discuss in explicit detail all of 
the steps associated with connecting a call between telephones 618 and 630. In 
other words, the text at column 12 lines 47-61 as cited in the Office action merely 
indicates that a user at telephone 61 8 connects to VRU 600 via gateway 606. It 
is important to keep in mind that note that, first, Cave discloses at column 12 
lines 62-64 that the H.323 communication standard is used to transmit 
information over a packet-based networks. This is because call connectivity 
depends on existing communication standards, namely, H.323 standard. 
Second, Cave discloses that a user at telephone 618 attempts to initially connect 
with VRU 600 (via a first dialed number) and not telephone 630 as stated in the 
Office Action. These two points are discussed in further detail below. 

It is well known that the H.323 standard utilizes a gatekeeper to translate 
incoming telephone numbers into appropriate network transport addresses 
associated with a packet-based network. For example, a user at a telephone 
dials a number of a party they are trying to reach. The number is transmitted 
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through a PSTN network to a gateway coupled to a packet-based network (such 
as a network supporting VOIP). To transmit over the packet-based network from 
the gateway, the gateway first needs to identify how to route the incoming call. 
This is achieved by forwarding the telephone number dialed by the user to the 
gatekeeper, which translates the number and provides the requesting gateway 
with an appropriate destination address (such as another gateway) to transmit 
future data packets associated with the users telephone call. Based on the 
H.323 standard discussed thus far, there is no intercepting of a request signal 
destined for another node as recited in the claimed invention. 

Although not cited by the Examiner, the "call connect" technique (e.g., the 
H.323 standard discussed above) is more specifically discussed with regard to 
FIG. 4a in Cave. Note this figure includes all of the same elements (e.g., 
gateways, gatekeeper, etc.) as FIG. 3. Regarding FIG. 4a, Cave specifically 
recites that: 

"Originating gateway 810 receives the call from the PSTN, and 
queries 818 domain gatekeeper 808 via IP network 806 for the PSTN- 
number-to-IP address translation, which is sent back 818 to gateway 810 
by gatekeeper 808. Originating gateway 810 then establishes H.323 call 
820 to CCS 802 in VRU 800. Q.931 call signaling identifies the source 
and destination and establishes a virtual signal connection between 
gateway 810 and VRU 800." (Cave, column 14, lines 23) 

The above passage recites a deliberate method for establishing connectivity 
between gateway 810 and VRU 800 based on a call from telephone 814 to VRU 
800. In no way does VRU 810 or any other device in Cave intercept a request 
message originally destined node for another node. All of the messages are 
specifically sent to particular nodes based on a corresponding protocol to 
establish communications as discussed. Additionally, and more significantly, no 
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network node in Cave intercepts a request signal (e.g., originally destined for 
another node) that, in response, generates control signals for controlling a 
manner or transferring a data stream instead of the originally destined node. 

As mentioned, it is important to understand that Cave is directed towards 
use of dialing an 800 number to purposefully connect a caller at telephone to a 
VRU (Voice Response Unit) that services the incoming call. For example, Cave 
is directed towards use of an 800 calling card to connect a caller to a VRU that 
services the incoming call (column 13, lines 41-53). Thus, a user at telephone 
618 dials a phone number associated with the calling card. Thus, there is no 
interception of a request signal destined for another network node. Gateway 606 
receives the communication signal and then must determine an IP address to 
route the call to a target. This is achieved by gateway 606 sending a query to 
gatekeeper 616, which responds with a network address as discussed above. 
This enables the system to connect telephone 618 to VRU 600. Up until this 
point, there is no attempt by gateway 606 to connect telephone 618 to telephone 
630. As its name suggests, VRU 600 then provides voice prompts and menus 
(column 14, lines 49-51 ) to the user at telephone 61 8. The caller then provides 
or dials another number to which the user is trying to reach such as a second 
number associated with telephone 630. VRU then sends the second number to 
gatekeeper 616 to identify a gateway associated with the target telephone 630. 
Based on a return of the destination address for gateway 626, VRU establishes a 
call between VRU 600 and target telephone 630. 

Thus, according to Cave, a request signal (such as a call by a user at 
telephone 618 or a signal generated by gateway 606) is not destined for a host 
computer that would otherwise respond with control information. Instead, as 
indicated by text in Cave, gateway 606 purposefully routes (based on packetized 
data and appropriate headers) a received 800 calling card call (based on an 800 
dialed number) to VRU 600. For example, a user specifically dials a number to 
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connect to VRU 600. There is no attempt at this point as indicated in the Office 
Action to connect to gateway 626 or telephone 630. VRU 600 accepts the call, 
provides a menu to a user at telephone 618 and receives a second number the 
user is trying to reach. VRU 600 establishes a connection with the target 
telephone 630 and, thereafter, generates control information to gateway 606 
identifying how to maintain a data stream directly between telephone 618 and 
telephone 630 (see horizontal dashed lines between gateway 606 and gateway 
626 of FIG. 3) to avoid a delay in sending data packets through network 602. 

Even the second number provided by the user at telephone 618 is not 
intercepted in a sense as described in claim 1 . For example, a user purposefully 
sends the second number to VRU 600 so that VRU 600 may thereafter establish 
a link between VRU 600 and telephone 630. This is also not intercepting a 
request signal destined for another address and providing control information 
instead. The second number is targeted to the VRU and is not intercepted along 
the way. 

Consequently, it is respectfully submitted that the technique as recited in 
claim 1 is not taught or suggested by the cited prior art. If the rejection of claim 1 
is to be maintained, Applicants respectfully request that it be pointed out with 
particularity where the cited prior art discloses a technique of intercepting a 
request signal and servicing it from other than an originally destined node. The 
Office Action discusses a mode of operation in Cave in which gateway 606 
attempts to communicate directly with gateway 626 to establish a call between 
telephones 618 and 630 without the presence of VRU 600. The cited reference 
does not support such a mode. 

In contradistinction to the technique disclosed by Cave, claim 1 recites 
that a request signal originally destined for a host computer is intercepted and 
serviced from a node other than the originally destined node (i.e., a node other 



U.S. Application No.: 09/4TO.777 Attorney DockeTOo.: CIS99-1717 

- 17- 



than the host computer). This alleviates the originally destined target node (e.g., 
host computer) from having to receive, process, and, thereafter generate a reply 
to the request signal. Thus, processing capability of the host computer is 
available for other tasks. 

Moreover, control information is still provided to the request signal source 
in the event that the host computer malfunctions (e.g., becomes inoperable due 
to a failure). For example, the intercepting node provides control information 
instead of the host computer. Thus, it does not matter if the host computer fails 
because the request signal source may properly route the data stream (based 
upon control information form the intercepting node) even though the originally 
destined recipient of the request signal is non-functional. This advantage is not 
supported by Cave. 

In addition to alleviating the originally destined host computer from having 
to respond, intercepting the request signal from an otherwise destined source 
reduces network traffic. For example, since the request signal is intercepted, it 
no longer needs to be forwarded by other nodes of the network to the originally 
destined node. In addition to reducing network traffic and congestion, control 
information may be provided more quickly to the request signal source because 
the request signal and the corresponding reply path is shorted (e.g., reply signal 
need not travel along the excess path between the intercepting node and the 
originally destined host computer). Thus, a data stream may be more efficiently 
maintained at the request signal source. 

For the reasons stated above, claim 1 is patentably distinct and 
advantageous over the cited prior art, and the rejection of claim 1 under 35 
U.S.C. §1 02(e) should be withdrawn. Accordingly, allowance of claim 1 and 
corresponding dependent claims 2-9 and 22-23 is respectfully requested. 
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Claim 10 includes similar limitations (e.g., an agent process intercepts a 
request signal otherwise destined for the host computer as well as use of a 
destination address to transmit the request signal to the host computer to which 
the request signal was originally destined) as recited in claim 1 above. For 
applicable reasons, claim 10 and corresponding dependent claims 11-18 and 24- 
26 are patentably distinct over the cited prior art. 

Rejections of Claims 2. 5. 6. 1 1 . 1 4, 1 5. 1 9 and 20 under 35 U.S. C. § 1 03(a) 

The Examiner has rejected claims 2, 5, 6, 11, 14, 15, 19 and 20 under 35 
U.S.C. § 103(a) based on the teachings of Cave, et al. f (U.S. Patent 6,404,746). 
Dependent claims 2, 5, 6, 1 1, and 15 should be allowable since corresponding 
independent claims 1 and 10 are allowable. 

Claim 19 includes similar limitations (e.g., an agent process that intercepts 
a request signal otherwise destined for the host computer) as recited in claim 1 
above. For applicable reasons, claim 19 and corresponding dependent claim 20 
are patentably distinct over the cited prior art. 

Patentability of New Claims 27-36 

Newly submitted independent claim 27 is directed towards use of a 
software agent to intercept a request signal generated by a routing mechanism, 
which at least partially supports transmission of a data stream between a data 
stream source and data stream recipient. Support for this new claim can be 
found in Figs. 1 and 2, text at page 8 line 7 to page 12 line 2, and elsewhere 
throughout the specification. Note that this claim is similar in some respects to 
originally submitted claim 1 . However, claim 27 includes further distinctions over 
the cited prior art. For example, the "request signal source" (a term used in claim 
1) is replaced with a "routing mechanism" (as recited in claim 27) to support 
transmission of the data stream through a network. Additionally, a "software 
agent" (disposed at the same node as the routing mechanism) intercepts a 
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request signal (generated by the routing mechanism) destined for a remotely 
located host computer. 

As previously discussed, the Office Action likens the request signal source 
generating the request signal in claim 1 to gateway 606 (as shown in Fig. 3) of 
Cave. Additionally, the Office action likens VRU 600 to the agent that intercepts 
the request signal. Note that VRU 600 and gateway 606 are remotely located 
with respect to each other as they are both coupled to edge nodes of packet 
network 602. In contradistinction, the claimed invention as previously mentioned 
is distinctive because the software agent intercepting the request signal resides 
at the same node as the routing mechanism. Based on this topology as recited 
in claim 27, the host computer to which the request signal was originally 
transmitted need not provide control information because the software agent acts 
on behalf of the host computer to provide control information. This alleviates the 
host computer from having to reply with control information. Since the software 
agent resides in the same network node as the routing mechanism, the request 
signal is intercepted before traveling on a network to the host computer. This 
reduces network congestion because the request signal no longer travels across 
the network to the host computer. Also, control information is not sent across a 
network to the routing mechanism. This also reduces network traffic. Moreover, 
based on the technique recited in claim 27, the software agent may respond 
more quickly to a request signal because the routing mechanism and software 
agent are disposed in the same node. That is, the request signal need not travel 
a long distance across a network to be serviced from a remote node. None of 
the cited references teach or suggest this topology nor its advantages. Thus, 
Applicants respectfully request allowance of independent claim 27. 

Newly submitted dependent claim 28 depends from claim 27 and recites 
that the host computer is also the data stream recipient that would otherwise 
reply with control information if the request signal was not intercepted by the 
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software agent. Support for this new claim can be found in Figs. 1 and 2, text at 
page 1 1 lines 3-15, and elsewhere throughout the specification. The limitation as 
recited in claim 28 further distinguishes the invention as in claim 27 over the cited 
art because gateway 626 would be the recipient of the data stream (according to 
the Examiner's analysis) and VRU 600 does not generate requests to gateway 
626 how to transfer the data stream. The invention as in claim 28 is beneficial 
over the cited art because the software agent provides control information on 
behalf of the data stream recipient. None of the cited references teach or 
suggest this technique nor its advantages. Thus, Applicants respectfully request 
allowance of independent claim 28. 

Newly submitted dependent claim 29 depends from claim 27 and recites 
that the host computer is also the data stream source that would otherwise reply 
with control information if the request signal was not intercepted by the software 
agent. Support for this new claim can be found in Figs. 1 and 2, text at page 1 1 
lines 3-15, and elsewhere throughout the specification. The limitation as recited 
in claim 29 further distinguishes the invention as in claim 27 over the cited art 
because gateway 606 would be the source of the data stream (according to the 
Examiner's analysis) and VRU 600 does not generate and transmit request 
signals to gateway 606 how to transfer the data stream. The invention as in 
claim 29 is beneficial over the cited art because the software agent provides 
control information on behalf of the data stream source. None of the cited 
references teach or suggest this technique nor its advantages. Thus, Applicants 
respectfully request allowance of independent claim 29. 

Newly submitted dependent claim 30 depends from claim 29 and recites 
that intercepting the request signal includes intercepting a request for permission 
to drop data packets associated with the data stream, the software agent 
responding to the request for permission to drop data packets received from the 
routing mechanism on behalf of and instead of the data stream source. Support 
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for this new claim can be found in Figs. 1 and 2, text at page 9 line 27 to page 10 
line 19, and elsewhere throughout the specification. The limitation as recited in 
claim 30 further distinguishes the invention as in claim 29 over the cited art 
because the cited prior art does not discuss dropping of data packets nor a 
request for permission to drop data packets associated with the data stream. 
According to claim 30, intercepting the request for dropping data packets 
(generated by the routing mechanism) via use a software agent disposed in a 
same node as the routing mechanism enables the routing mechanism to more 
quickly receive an indication whether it is acceptable to drop such data packets. 
For example, the request signal need not travel over a network to the host 
computer to be serviced. This also reduces overall congestion in the routing 
mechanism when it is more quickly granted permission to drop data packets. If 
permission is not granted to drop data packets, then routing mechanism may 
accordingly modify its scheduling of transmitting data packets. None of the cited 
references teach or suggest this technique nor its advantages. Thus, Applicants 
respectfully request allowance of independent claim 30. 



Newly submitted dependent claim 31 depends from claim 30 and recites a 
technique of, at the software agent, receiving configuration information from the 
remote host computer indicating when it is acceptable to drop data packets of the 
data stream. Additionally claim 31 recites a technique of, at the software agent, 
utilizing the received configuration information from the remote host computer to 
provide control information to the routing mechanism how to transfer the data 
stream. Support for this new claim can be found in Figs. 1 and 2, text at page 1 1 
lines 3-15, and elsewhere throughout the specification. The limitation as recited 
in claim 31 further distinguishes the invention as in claim 30 over the cited art 
because the cited prior art does not discuss, at the software agent, receiving 
configuration information from a host computer indicating when it is acceptable to 
drop data packets and utilizing the received configuration information from the 
remote host computer to provide control information to the routing mechanism 
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how to transfer the data stream. Instead, the cited Cave reference is silent as to 
dropping of data packets. This technique is advantageous because the remote 
host computer, although it does not receive the request signals, indicates to the 
software agent how to respond with control information so that the routing 
mechanism is properly informed how to transfer the data stream. Remote host 
computer may therefore define a policy for transmitting data packets. None of 
the cited references teach or suggest this technique nor its advantages. Thus, 
Applicants respectfully request allowance of independent claim 31 . 

Newly submitted dependent claim 32 depends from claim 31 and recites a 
technique of, in response to the routing mechanism dropping data packets of the 
data stream, generating and transmitting a message from the software agent to 
the remote host computer indicating when data packets of the data stream have 
been dropped. Support for this new claim can be found in Figs. 1 and 2, text at 
page 11 lines 3-15, and elsewhere throughout the specification. The limitation as 
recited in claim 32 further distinguishes the invention as in claim 31 over the cited 
art because the cited prior art does not discuss dropping of any data packets 
whatsoever. The technique recited in claim 32 is advantageous because the 
software agent notifies the remote host computer when data packets are dropped 
for better management of the data stream. Consequently, the remote host 
computer is aware of dropped data packets even though it does not provide 
control information in response to a request signal. None of the cited references 
teach or suggest this technique nor its advantages. Thus, Applicants respectfully 
request allowance of independent claim 32. 

New dependent claims 33-36 depend from independent claim 1 and are 
similar in scope to claims 29-32 as discussed above. For similar reasons, it is 
respectfully submitted that these new claims are in condition for allowance. 
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CONCLUSION 

In view of the foregoing remarks, this Application should be in condition for 
allowance. A Notice to this affect is respectfully requested. If the Examiner 
believes, after this Response, that the Application is not in condition for 
allowance, the Examiner is respectfully requested to call the Applicants' 
Representative at the number below. 

Applicant(s) hereby petition(s) for any extension of time which is required 
to maintain the pendency of this case. If there is a fee occasioned by this 
response, including an extension fee, that is not covered by an enclosed check, 
please charge any deficiency to Deposit Account No. 50-0901 . 

If the enclosed papers or fees are considered incomplete, the Patent 
Office is respectfully requested to contact the undersigned Attorney at (508) 366- 
9600, in Westborough, Massachusetts. 



Respectfully submitted, 




Paul P. Kriz, Esq. ) 
Attorney for Applicant(sr 
Registration No.: 45,752 
CHAPIN & HUANG, LL C. 
Westborough Office Park 
1700 West Park Drive 
Westborough, Massachusetts 01581 
Telephone: (508) 366-9600 
Facsimile: (508) 616-9805 
Customer No. 022468 
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